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Preface 


This  document  presents  the  Final  Technical  Report  of  the  Global  Command  and  Control  System 
(GCCS)  Spatial  Data  Base  Module  (SDBM)  effort  sponsored  by  Rome  Laboratory.  The  SDBM 
project  focused  on  the  design  of  a  geospatial  data  base  to  support  the  Mapping,  Charting, 
Geodesy,  and  Imagery  (MCG&I)  requirements  of  the  GCCS.  A  baseline  implementation  resulting 
from  the  design  was  developed  and  demonstrated  as  a  module  of  the  Joint  Mapping  Toolkit 
(JMTK). 

The  report  is  organized  into  five  sections  with  three  appendices.  The  introductory  section 
identifies  the  program  and  provides  a  background  of  the  effort  and  the  unique  objectives  that 
were  outlined  at  the  start  of  the  effort.  An  overview  of  the  specific  accomplishments  made 
during  the  effort  is  also  provided  in  the  introduction.  Section  2  provides  the  details  of  the 
technical  approach  used  to  achieve  the  objectives  of  the  effort.  A  complete  description  of  the 
Spatial  Data  Base  Module  is  presented  in  Section  3  that  includes  both  the  data  base 
architecture  and  the  software  components  to  utilize  it.  In  Section  4,  we  describe  additional  work 
performed  under  the  effort  to  support  the  development  of  the  GCCS/JMTK.  A  utility  that  was 
implemented  and  used  to  identify  functionality  needed  in  the  next  version  of  the  JMTK  is 
described  along  with  an  approach  for  migrating  from  the  Air  Force's  Common  Mapping  Toolkit 
(CMTK)  to  the  future  JMTK.  Section  5  ends  the  report  with  the  results  obtained  from  the 
prototype  developments  and  the  conclusions  and  recommendations. 

Major  Robert  Gibson  was  the  Rome  Laboratory /IRRP  Project  Engineer.  Mr.  Paul  Bell  was  the 
Sterling  Software  Project  Manager  who  directed  a  project  staff  that  included  Mr.  David 
Kolassa,  Mr.  Michael  McQuinn,  Ms.  Sandra  Stoltz,  Mr.  David  Kane,  Mr.  Michael  Seakan,  and 
Mr.  Robert  Marceau.  The  Sterling  Software  SDBM  project  team  is  grateful  to  the  leadership  and 
technical  support  provided  by  Major  Robert  Gibson  and  RL/IRRP  during  the  course  of  the 
effort.  We  are  also  grateful  to  Mr.  James  Kwolek,  Defense  Mapping  Agency  (DMA)  for  valuable 
data  production  and  operational  insights  that  helped  make  this  project  successful. 
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Section  l  Introduction 


1.1  Identification 

This  Final  Technical  Report  describes  the  activities  performed  by  Sterling  Software,  Information 
Technology  Division  (ITD)  under  the  Rome  Laboratory  (RL)  sponsored  program  entitled  the 
Global  Command  and  Control  System  (GCCS) /Joint  Mapping  Toolkit  (JMTK)  Spatial  Data 
Base  Module  (SDBM).  The  project  was  conducted  for  the  RL  Image  Products  Branch  (IRRP) 
with  the  end  customer  being  the  DMA.  This  nine  month  effort  developed  an  initial  Spatial  Data 
Base  Module  for  the  Joint  Mapping  Toolkit.  The  SDBM  will  be  used  within  the  JMTK  to  import 
and  maintain  native  DMA  products. 

1.2  Program  Background  and  Objectives 

The  GCCS  is  the  primary  joint  command,  control,  communications,  computer  and  intelligence 
systems  for  the  United  States  Department  of  Defense  (DoD).  GCCS  variants  (system  and 
workstation  configurations  of  GCCS  compliant  software)  utilize  applications  developed  by 
many  formal  acquisition  programs  (e.g..  Standard  Theater  Army  Command  and  Control 
System,  Contingency  Theater  Air  Control  System  Automated  Planning  System,  and  the 
Operations  Support  System)  to  provide  an  integrated  capability  at  most  levels  of  command. 
Development  of  GCCS  is  managed  by  the  Defense  Information  Systems  Agency  (DISA).  The 
GCCS  method,  architecture,  environment,  and  core  software  are  also  used  by  components  of  the 
DoD  (e.g.,  U.S.  Navy,  U.S.  Marine  Corps,  U.S.  Air  Force,  U.S.  Army,  DoD  Intelligence,  Defense 
Mapping  Agency,  etc.)  for  command  and  control  related  projects. 

Due  to  the  integration  philosophy  and  techniques  adapted  by  GCCS  projects,  DISA  and 
partner  organizations  are  able  to  now  field  more  capable  systems  cost  effectively.  By 
standardizing  the  way  the  software  is  built  and  integrated,  duplication  of  effort  is  avoided 
through  software  reuse.  Standardization  goes  beyond  the  structure  of  the  software.  Use  of 
common  software  to  achieve  certain  key  command  and  control  capabilities,  not  only  provides  a 
common  interface  for  client  software,  but  ensures  that  the  user  sees  predictable  behavior  and  a 
familiar  user  interface  for  capabilities  that  are  found  at  a  variety  of  command  centers.  Training 
requirements  are  thus  reduced  and  user  proficiency  is  increased.  Interoperability  also  results 
from  ensuring  that  critical  command,  control,  and  intelligence  data  is  processed  by  the  same 
software  regardless  of  what  GCCS  variant  is  being  used. 

GCCS  is  not  a  DoD  development  program.  There  is  no  prime  contractor  for  GCCS.  Rather 
GCCS  is  a  strategy,  technique,  and  set  of  standards  for  leveraging  the  development  efforts  of  a 
large  number  of  programs,  each  of  which  may  have  one  or  several  development  companies  and 
organizations.  All  participating  programs  benefit  from  the  work  done  by  other  organizations. 

As  a  response  to  shifting  budgetary  priorities  that  have  resulted  in  funding  reductions  for 
research  and  development  of  new  command  and  control  systems,  the  Department  of  Defense 
began  using  two  development  methods  that  significantly  differed  from  previous  practice.  The 
first  was  evolutionary  acquisition  or  development  (EA  or  ED).  A  system  developed  under  ED 
does  not  go  through  a  laborious  specification  process  before  development.  Instead  the  system  is 
built  up  and  fielded  in  a  series  of  increments. 
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The  second  concept  is  that  rather  than  building  a  large  system  broken  down  into  modules 
through  structured  analysis  (which  would  require  the  up  front  investment  in  the  specification 
process),  software  is  integrated  "up"  from: 

•  a  Common  Operating  Environment  (COE) 

•  existing  Commerciai-Off-The-Shelf  (COTS)  products 

•  Govemment-Off-The-Shelf  (GOTS)  software 

•  newly  developed  software  to  satisfy  the  needs  of  the  user  community 

This  approach  to  integrating  software  requires  that  the  software  operate  in  an  environment 
flexible  and  robust  enough  to  satisfy  the  resource  requirements  of  such  a  diverse  set  of  computer 
programs.  It  also  requires  that  software  products  be  built  and  selected  to  conform  to  a  rigorous 
set  of  standards  ensuring  that  all  application  will  come  together  as  one  entity. 

DISA  recently  decided  to  consolidate  command  and  control  systems  under  development  into  a 
single  architecture,  making  use  of  a  core  set  of  software  services.  These  projects  develop 
application  software  that  will  follow  strict  standards  and  use  common  core  products  for  all 
applicable  functions.  By  taking  this  approach,  software  developed  by  one  organization  can  be 
incorporated  at  any  type  of  command  center  simply  by  choosing  to  include  it  in  the  installed 
system.  This  approach  will  make  optimal  use  of  program  resources  and  increase  the  capabilities 
available  to  the  user  communities. 

The  Global  Command  and  Control  System  (GCCS)  has  a  binary  djmamic  library,  known  as  the 
Common  Operating  Environment  (COE),  as  a  universal  application  foundation.  The  COE  is 
divided  into  nineteen  functional  areas,  one  of  which  is  mapping.  This  portion  is  referred  to  as 
the  Joint  Mapping  Toolkit  (JMTK).  The  Joint  Services  Working  Group  gSWG)/COE  for  mapping 
has  been  formed  to  guide  and  facilitate  the  service  members  contributing  to  the  JMTK.  The 
JSWG/COE  members  have  divided  the  mapping  portion  of  the  COE  into  three  primary  areas. 
These  areas  are  1)  Visual,  2)  Non-visual  (analysis),  and  3)  Spatial  Data  Base.  Given  the 
ambitious  schedule  of  the  GCCS,  the  JSWG/COE  has  elected  to  tap  each  services'  assets  to 
provide  functionality  to  JMTK;  Navy's  Chart  II  software  to  fulfill  the  Visual;  Army's 
Topographic  Evaluation  Module  (TEM)  for  the  Non-visual;  and  the  Air  Force  Common 
Mapping  Toolkit  (CMTK)  for  the  Spatial  Data  Base  portion.  Software  modules  from  all  services 
may  well  migrate  and  integrate  into  all  areas  of  the  Mapping  COE  toolkit  in  due  time.  These 
selections  are  only  an  initial  departure  point  to  construct  a  Mapping  COE  toolkit  which  will 
allow  "first-start"  functionality  for  GCCS. 

The  primary  objective  of  this  SDBM  effort  is  to  define,  design,  develop,  and  test  mapping, 
charting  and  geodesy  (MC&G)  spatial  data  base  management  and  data  access  software  for 
inclusion  as  the  Spatial  Data  Base  Module  of  the  GCCS  COE  Joint  Mapping  Toolkit.  The 
Spatial  Data  Base  Module  utilized  the  current  CMTK  MC&G  software  as  the  basis  for  the 
initial  functionality  of  GCCS. 

The  baseline  Spatial  Data  Base  as  a  component  of  the  GCCS  /COE  JMTK  contains  the  following 
capabilities:  import  DMA  data  in  standard  formats  (VPF,  RPF,  DTED);  archive  DMA  data  in 
the  original  format  without  reformatting  any  data  (preprocessing);  and  provide  data  access  and 
retrieval  through  the  use  of  public  Application  Programmer  Interface  (API)  functions.  The 
information  contained  in  this  final  report  represents  a  summary  of  the  SDBM  program 
background,  objectives,  technical  approach,  and  functional  capabilities  of  the  SDBM  Import 
application,  public  APIs,  thread  tracking  capability,  and  SDBM/CMTK  integration  prototype 
performed  and  developed  under  this  effort. 


1 . 3  Summary  of  Accomplishments 

Five  major  accomplishments  were  achieved  during  the  SDBM  contract.  The  first  of  these 
accomplishments  was  the  development  of  an  SDBM  Import  application.  The  SDBM  Import 
application  is  a  graphical  application  used  to  assist  in  the  creation  of  spatial  data  bases,  the 
importation  of  standard  DMA  data,  and  the  building  of  metadata.  The  second  significant 
accomplishment  was  the  development  of  the  public  as  well  as  private  API  functions.  Eleven 
public  API  functions  were  developed  and  used  within  the  SDBM  Import  application  as  well  as 
thirty-three  private  API  functions  in  support  of  the  public  API  functions.  The  API  functions 
were  developed  and  documented  according  to  JMTK  Working  Group  standards.  A  Thread 
Tracking  utility  was  developed  during  this  effort  to  provide  developers,  users,  and  integrators 
of  JMTK  with  the  capability  to  track  the  functional  hierarchy  (function  threads)  of  functions 
within  a  toolkit  such  as  SDBM  in  order  to  support  the  analysis  and  documentation  of  the 
functional  flow  within  the  API. 

A  CMTK-to-JMTK  migration  plan  was  developed  during  the  SDBM  effort.  This  plan  provides 
an  approach  for  current  CMTK  users  to  gradually  transfer  from  the  CMTK  to  the  JMTK  without 
introducing  redevelopment  costs  or  causing  a  delay  in  program  development  due  to  the 
migration  of  CMTK  to  JMTK.  This  plan  received  enthusiastic  support  during  every  briefing. 

The  final  notable  accomplishment  of  this  effort  was  the  development  of  a  prototype 
demonstration  which  presented  the  feasibility  of  the  initial  step  of  the  CMTK-to-JMTK 
migration  plan,  the  integration  of  the  SDBM  into  CMTK.  The  purpose  of  this  demonstration 
was  to  show  that  an  end  user  application  would  not  require  modification,  standard  DMA  data 
could  be  used,  preprocessing  data  could  be  eliminated,  and  access  to  the  data  in  the  standard 
format  are  all  possible. 

During  this  contract  the  following  deliverables  and  technical  documentation  were  delivered: 
Monthly  Status  Reports,  Spatial  Data  Base  and  Data  Access  Requirements  Document,  SDBM 
User's  Manual,  SDBM  Implementation  Plan,  Software  Test  Description,  Software  Test  Plan, 
Presentation  Materials,  Configuration  Management  Plan,  SDBM  Computer  Software  (C  with 
Ada  Bindings),  Error  Handling  Approach  within  SDBM,  Thread  Tracking  Capability,  SDT 
Thread  Analysis,  and  the  Software  Engineering  Practices. 
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Section  2  Program  Overview 


2.1  Functional  Analysis 

In  the  area  of  MCG&I,  each  of  the  Joint  forces'  individual  services  has  maintained  its  own 
software  products  which  perform  MCG&I  functionality.  Although  that  functionality  is  quite 
similar  among  software  products,  the  implementation  of  the  functionality  is  not.  It  is  to  this  end 
that  the  GCCS  is  attempting  to  incorporate  a  COE  to  provide  just  that  functionality.  The  GCCS 
has  been  attempting  to  obtain  the  best  portion*  of  each  of  these  software  products  and 
integrate  them  into  a  JMTK  environment. 

Sterling  Software  took  the  initiative  to  perform  a  functional  analysis  on  a  group  of  these 
software  products  to  analyze  re-use  opportunities  prior  to  the  design  and  development  of  the 
GCCS  SDBM.  Under  this  effort.  Sterling  Software  compiled  a  significant  amount  of  functional 
data  from  a  wide  variety  of  sources.  The  information  was  compiled  from  the  JMTK  Software 
Requirements  Specification  (SRS)  Document,  the  currently  existing  requirements  produced  by 
the  JMTK  Working  Group  and  specified  within  the  GCCS  SDBM  Statement  of  Work  (SOW), 
and  requirements  from  such  systems  as  the  Air  Force  Mission  Support  System  (AFMSS)  and 
Theater  Battle  Management  Core  System  (TBMCS).  After  gathering  this  information  under  one 
cover.  Sterling  produced  its  own  SRS  based  upon  the  gathered  information.  The  results  from  this 
functional  analysis  drove  the  design  of  the  GCCS  SDBM  for  the  Joint  Mapping  Community. 

2 . 2  Module  Design 

The  objective  of  this  phase  was  to  define  and  design  MC&G  spatial  data  base  management  and 
data  access  software  for  inclusion  as  the  Spatial  Data  Base  Module  of  the  Global  Command 
and  Control  System  Core  Operating  Environment  Joint  Mapping  Toolkit.  The  SDBM  was 
designed  to  be  one  of  three  architecture  components  of  the  JMTK,  with  the  other  two 
components  consisting  of  the  Visualization  Module  (displays  of  maps  and  overlays),  and  the 
Analysis  Module  (terrain  analysis,  line  of  sight,  etc.). 

Sterling  Software  defined  the  spatial  data  base  and  data  access  requirements  for  the  GCCS 
SDBM  effort  through  two  means: 

1 .  By  providing  assistance  and  becoming  actively  involved  with  the  JMTK  Working  Group,  to 
define  the  Application  Programming  Interface  for  the  Spatial  Data  Base  and  Data  Access 
software. 

2.  By  analyzing  existing  DMA  MCG&I  datasets  (e.g.,  CADRG,  VMAP  Level  0,  DTED,  etc.)  to 
define  data  commonalty  among  the  various  mapping  products  and  provided  proposed 
solutions  to  limit  and/ or  eliminate  redundant  data. 

Under  the  Module  Design  of  this  effort.  Sterling  Software  designed  a  GCCS  SDBM  which  was 
compliant  with  the  GCCS  COE  Data  Management,  Data  Access,  and  Data  Interchange 
Services.  This  module  provided  full  support  for  the  access  and  data  base  management  of 
MCG&I  data  required  by  the  GCCS  JMTK  Visualization  and  Nonvisualization  modules.  This 
task  was  achieved  by  examining  and  thoroughly  understanding  the  current  COE  components. 
Sterling  Software  designed  data  base  management  functions  for  the  GCCS  SDBM  which 
incorporated  the  following  functionality: 
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•  store  graphical  data  such  as  Vector  Product  Format  (VPF)  data.  Raster  Product  Format 
(RPF),  and  Digital  Terrain  Elevation  Data  (DTED) 

•  store  analysis  data  for  functions  such  as  mobility  and  terrain  analysis 

•  query  and  retrieve  data  base  files,  against  both  on-line  and  off-line  product  data  bases,  by 
geographic  coordinate  and  product  type 

•  provide  access  to  the  graphical  and  analysis  data  for  functions  such  as  mobility  and  terrain 
analysis 

•  obtain  metadata  on  imported  graphical  data  such  as  file  size,  file  content,  data  base 
accuracies,  fcature/attribu'ee  information,  and  other  metadata  in  accordance  with  Federal 
Geographic  Data  Committee  (FGDC)  ivletadata  Content  Standard 

The  data  base  management  functions  designed  under  this  phase  for  the  GCCS  SDBM 
maintained  a  consistency  with  the  specifications  identified  within  the  Functional  Specification 
for  the  Joint  Mapping  Toolkit  as  those  specifications  pertain  to  the  task  of  data  base 
management  for  the  JMTK  and,  therefore,  the  GCCS  SDBM.  Sterling  Software  also  designed  a 
COE-compliant  DIS  to  import  and  export  MCG&I  datasets  and  associated  metadata  to  and 
from  the  GCCS  SDBM.  The  DIS  design  allowed  for  the  import  and  export  of  MCG&I  datasets  in 
their  native  DMA  formats.  The  DIS  design  also  allowed  the  datasets  to  be  accessible  from  the 
associated  storage  media  of  each  data  type. 

2.3  Development  and  Integration 

Sterling  Software  has  developed  an  initial  baseline  of  the  Spatial  Data  Base  Module.  The  initial 
implementation  includes  the  support  of  CADRG,  DCW,  and  DTED  datasets,  and  associated 
metadata.  The  initial  implementation  performs  the  Data  Base  Management  functions,  the  Data 
Access  Functions,  and  the  Data  Interchange  Service  functions  described  in  Section  2.2  and 
relevant  to  the  support  of  the  datasets. 

All  computer  software  designed  and  developed  for  this  effort  adheres  to  MTL-STD-498,  entitled 
Software  Development  and  Documentation,  dated  5  December  1994.  Also,  all  SDBM  software 
APIs  have  been  developed  in  C  and  with  supporting  ADA  bindings.  All  software  delivered 
under  this  task  is  completely  maintainable  and  modifiable  with  no  reliance  on  any  non- 
delivered  computer  programs  and  documentation.  All  software  has  been  developed  and  tested 
under  the  following  platforms  and  operating  systems: 

•  Sun  Workstation  -  Solaris  2.4,  SunOS  4.1.3 

•  Hewlitt  Packard  -  HP-UX  10.0.1 

All  JMTK  software  components  are  compatible  with  the  following  commercial  and  public 
software  versions: 

•  X11R5 

•  OSF  Motif  1.2.2 

The  GCCS  SDBM  software  has  undergone  multiple  integration  steps  through  its  life  cycle. 
Sterling  Software  supported  all  integration  activities  in  accordance  with  the  GCCS  Integration 
Standard.  The  following  identifies  the  main  areas  of  integration  that  Sterling  Software  has 
supported: 

•  integration  of  the  MCG&I  data  server  into  the  GCCS  COE 

•  integration  of  all  SDBM  APIs  and  functional  software  into  the  GCCS  JMTK 
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Sterling  Software  provided  continuous  support  in  the  above  areas  throughout  the  SDBM  task.  In 
assisting  in  the  integration  effort  of  the  GCCS  SDBM,  Sterling  Software  utilized  the  Telnet 
communication  capabilities  that  were  established  during  this  SDBM  effort,  and  that  has  proven 
to  be  a  highly  efficient  method  of  integration,  trouble  shooting,  and  maintenance  support  for  this 
effort. 

2.4  Testing 

The  GCCS  SDBM  software  has  undergone  rigorous  testing  throughout  the  development  cycle  of 
this  effort.  Modularized  software  has  been  tested  thoroughly  by  each  individual  engineer 
responsible  for  a  particular  unit/portion  of  software  that  was  developed  before  it  was 
integrated  into  the  baseline  of  SDBM.  The  baseline  SDBM  was  also  thoroughly  tested  on  a 
regular  basis  to  ensure  that  incorporation  of  software  modules  function  were  well  within  the 
bounds  of  the  SDBM. 

Sterling  Software  performed  extensive  test  procedures,  at  the  Sterling  Rome,  NY  office,  of  all 
capabilities  of  the  GCCS  SDBM  enhancements  in  order  to  verify  that  all  requirements  for  the 
GCCS  SDBM  effort  were  met  upon  the  conclusion  of  this  effort.  A  Software  Test  Description 
document  has  been  written  to  direct  and  present  the  format  of  the  test  plan,  test  descriptions, 
and  test  procedures  for  the  GCCS  SDBM  effort.  Equivalent  test  procedures  were  performed 
following  the  Software  Test  Description  document  at  the  designated  Government  facility  upon 
installation  of  the  GCCS  SDBM  enhancements.  A  Software  Test  Plan  was  also  written  and 
provided  to  the  Government  in  order  to  specify  the  exact  times,  dates,  locations,  etc.,  at  which 
the  formal  test  procedures  were  conducted. 

To  ensure  that  the  SDBM  API  functions  were  fully  operational,  an  additional  software  testing 
tool  was  developed  specifically  to  test  each  SDBM  API  function.  The  APITESTER  was 
developed  by  the  Sterling  Software  SDBM  project  engineers  to  test  each  API  function  before  it 
was  integrated  into  the  SDBM.  The  APITESTER  allowed  for  all  tests  to  be  performed  in  a 
known  environment  with  the  use  of  predesignated  steps  and  inputs  to  produce  results  that 
could  be  observed  and  used  to  evaluate  the  overall  operation  of  each  API  function. 

2.5  Prototype  Development  and  Demonstration 

Sterling  Software  prepared  and  presented  a  final  technical  briefing  and  demonstration,  at  the 
Sterling  Rome,  NY  office,  which  covered  all  of  the  accomplishments  under  the  GCCS  SDBM 
contract  and  addressed  a  portion  of  the  CMTK-to-JMTK  migration  issues.  A  prototype 
application  was  developed  by  the  Sterling  Software  SDBM  engineering  staff  to  demonstration 
the  capabilities  of  integrating  SDBM  into  CMTK.  This  prototype  application  addressed  the 
issues  of  accessing  data  through  the  SDBM  and  displaying  the  results  in  a  CMTK  application. 
The  DMA  products  that  were  demonstrated  were  Compressed  ARC  Digital  Raster  Graphics 
(CADRG),  Vector  Smart  Map  (VMAP)  Level  0,  and  Digital  Terrain  Elevation  Data  (DTED).  A 
Thread  Tracker  application  was  also  developed  and  submitted  to  the  Government  in  order  to 
provide  a  means  to  identify  and  document  functional  threads  within  an  application  or  toolkit, 
such  as  CMTK,  and  to  provide  support  to  developers  and  integrators. 
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Section  3  Module  Description 


The  Joint  services  have  previously  developed  and  maintained  their  own  software  products  to 
support  MCC&I  requirements.  Although  functionality  is  shared  by  the  individual  mapping- 
applications,  each  implementation  is  unique.  To  provide  the  Joint  services  with  a  set  of  common 
capabilities  and  a  common  implementation,  the  GCCS  program  is  working  towards  the 
development  of  a  COE.  MCG&I  is  just  one  of  many  functional  areas  within  the  COE 
architecture  being  addressed  by  the  development  of  a  Joint  Mapping  Toolkit,  which  includes  Lite 
Spatial  Data  Base  Module,  the  topic  of  discussion  in  this  Final  Technical  Report. 

The  JMTK  is  being  developed  as  a  collection  of  APIs  that  enable  support  applications  to 
interface  with  MCG&I  functionality.  Version  3.0  of  the  JMTK  is  comprised  of  three  distinct 
modules:  the  Visual  Module,  which  provides  map  presentation  functionality;  the  Analysis 
Module  which  performs  geospatial  computations;  and  the  Spatial  Data  Base  Module,  which 
provides  the  geospatial  data  management  services. 

The  Spatial  Data  Base  Module  operates  in  two  modes,  interactive  and  server.  The  interactive 
mode  supports  all  the  user  directed  activities  required  by  the  Spatial  Data  Base  Module.  This 
includes  the  capabilities  to  import,  manage,  and  export  the  data.  The  server  mode  encompasses 
all  the  capabilities  to  supply  information  to  a  JMTK  application.  Examples  are  the  queries  for 
metadata,  queries  to  locate  specific  data,  reporting  of  data  dictionary  entries,  and  the 
reformatting  of  data.  Figure  3-1  correlates  the  capability  requirements  of  SDBM  with  these 
modes.  Of  the  five  capability  areas,  the  requirements  levied  on  JMTK  3.0  for  the  development  of 
the  SDBM  encompassed  three  of  the  capability  areas:  Spatial  Data  Import,  Spatial  Data 
Management,  and  Spatial  Data  Services. 


SDBM  CAPABILITY 


MODE 


Server 


Interactive  f 


Spatial  Data  Import 

Populate  the  spatial  database. 

x  1 

Spatial  Data  Management 

Manage  the  spatial  database  holdings . 

X 

Spatial  Data  Manipulation 

Transform  data  holdings  into  a  form 
other  that  the  original  input  format 

X 

Spatial  Database  Service 

Provide  information  about  data  holdings 
and  data  contained  in  the  spatial  database. 

X 

Spatial  Data  Export 

Output  database  holdings  for  external  use. 

X  j 

Figure  3-1.  SDBM  Modes 
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The  following  sections  of  this  Final  Technical  Report  describe  the  Spatial  Data  Base 
architecture,  the  set  of  Application  Programmer  Interface  functions  provided  by  version  3.0  of 
JMTK,  and  the  Spatial  Data  Import  Application  developed  to  provide  a  means  of  populating  a 
spatial  data  base. 

3.1  Spatial  Data  Base  Architecture 

The  Spatial  Data  Base  Module  architecture  is  based  on  a  hierarchical  directory  structure  of 
metadata.  Figure  3-2  depicts  this  Spatial  Data  Base  metadata  directory  structure.  Three  levels 
of  metadata  summarize  the  actual  standard  DMA  data.  The  metadata  does  not  contain  any 
actual  data  within  the  structure:  it  simply  describes  the  data  and  provides  information  as  to 
where  the  data  is  actually  located. 


Level  1  metadata  provides  an  overview  of  the  entire  data  base.  Each  data  base  is  named  at 
creation.  The  action  of  creating  a  new  data  base  causes  a  directory  structure  to  be  built  within 
the  Spatial  Data  Base  environment.  The  directory  is  labeled  with  the  data  base  name  and  an 
initial  metadata  structure  is  placed  within  that  directory.  This  metadata  structure  is  continually 
updated  as  datasets  are  added  to  the  data  base.  A  format  directory  (i.e.,  VPF,  RPF,  ELV)  is 
added  beneath  the  data  base  directory  each  time  a  new  format  is  presented  for  import.  No 
metadata  is  associated  with  this  directory  level. 

Level  2  metadata  contains  information  describing  volume  metadata  (i.e.,  DCW,  CADRG, 
DTED)  and  all  datasets  of  a  particular  volume.  Each  time  a  new  data  type,  or  volume,  of  data 
is  imported  into  the  data  base  a  directory  is  built  beneath  the  appropriate  Format  directory  to 
indicate  the  new  data  type.  The  metadata  at  the  volume  level  and  at  the  data  base  level  are 
updated  to  reflect  the  addition  of  the  new  data. 

Level  3  metadata  contains  information  describing  a  particular  dataset  which  has  been  imported 
into  a  particular  data  base.  As  a  new  dataset  is  imported  into  a  data  base,  a  directory  structure 
is  built  beneath  the  appropriate  volume  directory  and  all  three  levels  of  metadata  are  updated 
accordingly. 
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For  the  JMTK  3.0  delivery,  a  dataset  is  equivalent  to  a  compact  disk  (CD)  distributed  by  DMA 
containing  standard  DMA  formatted  data  (i.e.,  VPF,  RPF,  DTED).  Future  versions  of  JMTK  will 
allow  a  dataset  to  represent  a  portion  of  data  taken  from  a  CD.  The  data  itself  represented  by 
the  metadata  can  remain  on  CD,  or  it  can  be  placed  on  hard  disk  during  the  import  process  for 
JMTK  3.0. 

The  three  levels  of  metadata  within  the  Spatial  Data  Base  architecture  will  develop  and  mature, 
providing  additional  information  about  the  actual  data  as  future  releases  of  JMTK  develop  and 
mature. 

3.2  Application  Programmer  Interface  (API) 

As  depicted  in  Figure  3-3,  the  Application  Programmer  Interface  for  JMTK  provides  a  means  of 
interaction  between  common  and  service  specific  applications  and  a  JMTK  environment.  The 
JMTK  environment  consists  of  the  three  distinct  modules,  the  Visual  Module,  the  Analysis 
Module,  and  the  Spatial  Data  Base  Module.  An  initial  set  of  module-related  API-level  functions 
have  been  developed  for  each  of  these  modules  within  JMTK  3.0  in  order  to  provide  a  common 
and  consistent  view  of  the  battlefield  to  all  military  players.  Future  versions  of  JMTK  will  build 
upon  the  initial  baseline  to  provide  additional  functionality  in  increments. 


Service  Specific  Application  Common  Application 

. . —  . .  -  .  API  -  "  = 


Other  MCG&I  Data  DMA  Data  Analytical  Results 


Figure  3-3.  GCCS  JMTK  3.0  Architecture 


Eleven  public  API  functions  have  been  delivered  to  provide  for  the  access  of  the  Spatial  Data 
Base  Module  functionality.  Thirty-three  private  API  functions  have  been  delivered  in  support  of 
these  eleven  public  APIs.  All  the  APIs  have  been  developed  and  documented  in  accordance 
with  the  JMTK  Working  Group  Standards. 

The  following  is  a  brief  description  of  the  eleven  public  APIs  provided  for  interaction  with  the 
Spatial  Data  Base  Module  of  JMTK  3.0: 

JMS_ConfigAOIGet  Allows  for  retrieval  of  the  current  Area-of-Interest  (AOI) 

setting  for  the  current  data  base  connection. 
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JMS_ConfigAOISet  Defines  the  geographic  area  of  a  spatial  data  base  (i.e., 

current  data  base  connection)  that  will  be  used  by 
subsequent  application  calls. 

JMS_DataPathnameGet  Provides  path(s)  to  the  actual  dataset(s)  found  in  a 

particular  volume  located  in  a  particular  data  base 
indicated  by  the  current  data  base  connection. 

Establishes  a  unique  connection  to  a  currently  existing 
JMTK  spatial  data  base. 

Terminates  a  JMTK  data  base  connection. 

Retrieves  a  list  of  data  base  names  that  have  been 
imported  into  the  JMTK  spatial  data  base  environment. 

Provides  a  means  of  retrieving  an  error  message  string 
related  to  an  error  code  when  an  error  occurs  during 
execution  of  an  API  call  to  the  Spatial  Data  Base  Module. 

JMSJnventoryGet  Provides  a  means  of  retrieving  the  list  of  volumes  and 

associated  format  types  for  a  particular  data  base 
indicated  by  the  current  data  base  connection. 

JMS  MatrixGet  Provides  a  means  of  obtaining  user-defined  matrix  data 

from  the  Spatial  Data  Base. 

JMS  MatrixPut  Provides  a  means  of  storing  user-defined  matrix  data  in 

J  ~  the  Spatial  Data  Base  in  a  way  that  can  be  maintained  by 

the  SDBM. 

jMS_MetadataGet  Provides  a  means  of  retrieving  user  requested  items  from 

the  three  levels  of  metadata  within  a  particular  data  base 
indicated  by  the  current  data  base  connection. 


JMS_Db  Connect 

JMS_DbDisconnect 

JMS_DbListGet 

JMS_ErrorGet 


3.3  Import  Application 

An  SDBM  Import  application  was  developed  during  this  effort.  The  application  provided  the 
JMTK  Spatial  Data  Base  Module  developers  with  a  means  of  populating  a  Spatial  Data  Base  in 
the  context  of  a  JMTK  environment.  It  also  provided  a  valuable  means  for  testing  the  API-leve 
functions  required  for  the  JMTK  3.0  delivery.  Figure  3-4  depicts  the  initial  startup  window  of 
the  SDBM  Import  application.  SDBM  Import  users  can  use  the  application  to  create  new  data 
bases,  import  standard  DMA  data  to  a  data  base,  populate  and  maintain  the  SDBM  metadata 
describing  the  datasets,  verify  the  format  of  a  standard  DMA  product,  and  review  data  types 
available  in  each  data  base. 

It  is  expected  that  this  application  will  evolve  into  an  SDBM  developer's  tool  for  future  versions 
of  JMTK.  The  way  in  which  it  was  written  provides  a  baseline  tool  which  can  be  expanded 
accordingly  to  assist  in  the  development  of  additional  API-level  functions,  provide  a  resource 
for  testing  functionality,  provide  a  resource  for  regression  testing,  and  provide  a  method  for 
quickly  populating  a  Spatial  Data  Base  for  future  versions  of  JMTK. 
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Section  4  Prototype  Integration 


4.1  Thread  Tracking  Capability 

The  Thread  Tracking  Utility  developed  under  this  effort  was  used  to  assist  in  the  prototype 
integration  of  SDBM  into  the  CMTK.  The  MACS/Sdt  application  was  exercised  with  the 
Thread  Tracker  in  use.  Through  the  use  of  the  Thread  Tracker,  UNIX  utilities,  and  code  review, 
it  was  determined  that  160  CMTK  API  functions  are  currently  used  by  the  MACS/Sdt 
application.  These  functions  were  categorized  into  four  functional  areas:  Visual  functions. 
Spatial  Data  Base  functions.  Analysis  functions,  and  Utility  functions.  The  160  identified 
CMTK  functions  represent  the  mapping  functionality  required  by  most  U.S.  Air  Force 
applications  using  MaCS/CMTK.  It  is  these  functions  that  are  targeted  for  inclusion  in  JMTK  in 
order  to  accommodate  CMTK  users  migrating  to  JMTK.  The  results  of  this  phase  of  prototype 
integration  were  documented  in  a  Software  Engineering  Note. 

4 . 2  Migration  Approach 

The  CMTK-to-JMTK  migration  approach  consists  of  three  phases.  Phase  One  was  implemented 
for  the  Prototype  Demonstration  in  order  to  demonstrate  the  proof-of-concept.  Phase  One 
entailed  the  replacement  of  the  CMTK  Preprocessor  with  the  Spatial  Data  Base  Manager  Import 
application.  The  import  application  provided  a  means  of  importing  the  standard  DMA  data 
into  a  data  base  environment  for  use  by  the  CMTK.  An  interface  layer  was  then  built  between 
the  CMTK  data  access  calls  and  the  SDBM  API.  This  provided  access  to  the  standard  DMA 
data,  rather  than  the  preprocessed  Common  Mapping  Standard  (CMS)  data.  The  results  of 
Phase  One  expanded  CMTK's  data  sources  to  include  standard  formatted  DMA  data  as  well 
as  CMS  data,  alleviating  the  use  of  the  preprocessor  (100,000  lines  of  source  code)  and 
replacing  it  with  the  GCCS/JMTK  Import  application  (20,000  lines  of  source  code).  A 
significant  result  of  the  Phase  One  integration  is  that  existing  CMTK  applications  remain 
identical  to  the  end  user. 

Phases  Two  and  Three  are  future  steps  of  the  CMTK-to-JMTK  migration  plan  and  were  not 
incorporated  into  the  prototype  demonstrating  the  proof-of-concept.  Phase  Two  consists  of 
building  an  interface  layer  between  the  existing  CMTK  APIs  and  the  JMTK  APIs.  The  interface 
layer  would  be  organized  into  "bindings"  which  would  replace  the  existing  CMTK  libraries.  This 
will  take  the  proof-of-concept  one  step  further  to  a  completely  functional  CMTK  application.  It 
would  also  identify  any  capabilities  that  are  missing  from  JMTK.  There  would  be  no 
redevelopment  costs  for  existing  CMTK  applications  to  migrate  to  using  the  JMTK. 

The  third  and  final  phase  of  the  CMTK-to-JMTK  migration  plan  consists  of  calling  JMTK 
directly  as  new  functionality  is  added  to  a  program.  The  interface  layer  would  be  gradually 
eliminated  as  warranted.  The  result  of  this  three  phase  migration  plan  is  that  existing 
applications  transition  to  JMTK  in  a  logical  manner  with  minimal  impact  to  the  program  effort 
using  the  CMTK  application. 

4.3  Prototype  Demonstration 

The  approach  Sterling  took  in  developing  a  demonstration  that  would  show  the  feasibility  of 
Phase  One  of  the  CMTK-to-JMTK  Migration  Plan  entailed  several  key  points.  First,  an  area  of 
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interest  was  selected  where  both  CMS  and  standard  DMA  data  were  available.  Relief  shading 
was  selected  as  the  functionality  to  demonstrate  the  use  of  DTED.  Vector  display/overlay  was 
selected  to  be  used  to  demonstrate  the  use  of  VPF  data,  and  CADRG  data  was  selected  to  be 
used  for  the  display  of  raster  data.  New  SDBM  API  functions  were  developed  to  provide 
access  to  the  standard  VPF  and  DTED  data  types.  The  access  of  CADRG  was  previously 
incorporated  into  CMTK,  therefore  that  functionality  was  used  Lo  display  the  CADRG  data. 
Finally,  the  SDBM  API  functions  were  integrated  with  CMTK  v3.2  Beta.  The  application  used 
to  call  the  toolkit  functions,  G-Odesy,  was  not  modified  in  any  way  in  order  to  accomplish  this 
demonstration. 

The  data  used  for  the  prototype  demonstration  consisted  of  100  meter  resolution  preprocessed 
DTED,  Digital  Chart  of  the  World  (DCW)  (preprocessed  vector  data),  and  CADRG  to 
represent  the  CMS  data.  Also  used  was  standard  DMA  data  in  the  forms  of  CADRG  (RPF), 
100  meter  DTED,  and  VMAP  Level  0  (VPF).  Duplicate  hardware  configurations  were  used  to 
demonstrate  the  prototype  and  the  original  CMTK  simultaneously.  On  one  platform  the  original 
CMTK  was  exercised  via  the  G-Odesy  application.  G-Odesy  was  also  used  on  the  other 
platform  to  exercise  the  modified  version  of  CMTK  which  integrated  SDBM  to  access  the 
standard  format  DMA  data. 

To  achieve  the  demonstration,  several  modifications  to  the  CMTK  software  were  made  and 
additional  API  functions  were  developed  to  access  standard  DMA  data  sources  stored  by  the 
SDBM.  The  additional  API  functions  included  JMS_VPFListGet,  JMSJVPFDataRetrieve, 
JMS_ELVListGet,  and  JMS_ELVRetrieve.  At  this  point,  no  additional  indexing  of  the  standard 
DMA  data  was  performed.  To  demonstrate  the  proof-of-concept,  only  five  CMTK  source  code 
files  and  two  include  files  were  modified  in  order  to  provide  access  to  standard  DMA  data  via 
the  Spatial  Data  Base  Module. 

The  results  of  the  prototype  demonstration  showed  that  integration  of  GCCS/JMTK  SDB  into 
the  CMTK  is  feasible.  The  end  user  application  did  not  require  modification  in  any  way  in  order 
to  use  the  SDBM  Importer  to  acquire  its  data.  Standard  DMA  data  was  utilized  successfully, 
therefore  preprocessed  data  was  not  necessary.  The  display  performance  of  standard  DMA 
DTED  data  via  SDBM  was  50%  faster  than  preprocessed  CMS  data  at  the  100  meter 
resolution;  the  display  performance  of  standard  DMA  DTED  data  via  SDBM  was 
approximately  40%  slower  than  preprocessed  CMS  data  at  the  800  meter  resolution  due  to  the 
fact  that  the  DMA  data  had  to  be  reformatted  from  100  meter  resolution  on  the  fly  and  the 
CMS  data  was  accessed  as  800  meter  immediately.  The  display  performance  of  VPF  data  was 
slightly  slower  than  that  of  comparable  CMS  data,  however  the  display  performance  would  be 
improved  by  incorporating  additional  data  indexing  into  the  SDBM. 

Two  benefits  were  immediately  realized  through  the  prototype  demonstration.  By  using  the 
standard  DMA  DTED  data  at  multiple  resolutions,  there  is  a  reduction  of  storage  requirements. 
The  CMS  data  would  need  to  be  preprocessed  and  stored  at  every  level  of  resolution  required 
for  display,  however  standard  DMA  data  could  be  used  at  the  finest  resolution  possible  and 
then  culled  in  order  to  provide  a  less  accurate  resolution  when  that  is  sufficient.  The  fact  that 
data  does  not  require  preprocessing  provides  a  second  benefit;  it  reduces  the  costs  associated 
with  the  building  and  maintenance  of  cartographic  data  bases  -  a  preprocessor  is  not  required 
to  be  used,  maintained,  and  exercised  in  order  to  build  a  cartographic  data  base  for  SDBM. 
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Section  5  Summary 


5.1  Results 

The  GCCS  SDBM  effort  commenced  with  an  in  depth  analysis  of  the  overall  purpose  of  the 
effort.  By  taking  the  results  from  this  analysis,  a  detailed  study  and  correlation  of  data  was 
conducted  to  identify  the  spatial  data  base  management  and  data  access  functions  that  might 
be  needed  to  satisfy  the  requirements  identified  by  the  JMTK  Working  Group  and  the  GCCS 
SDBM  SOW.  The  results  of  this  activity  produced  the  following  documents:  Software 
Requirements  For  The  JMTK  Spatial  Data  Base  Module  and  the  Spatial  Data  Base  (SDB) 
Module  Version  3.0  API  Document.  The  defined  functionality  included  the  creation  and 
manipulation  of  data  bases;  the  creation,  manipulation,  and  retrieval  of  p:  •••duct  datasets 
associated  with  the  data  bases;  and  the  creation  and  manipulation  of  metadata  associated 
with  the  product  datasets.  The  API  functions  identified  in  this  phase  of  the  effort  guided  the 
remainder  of  the  GCCS  SDBM  effort. 

The  second  phase  of  the  GCCS  SDBM  effort  entailed  the  design,  implementation,  integration, 
and  test  of  targeted  API  functions.  This  part  of  the  effort  was  aided  by  the  design  and 
development  of  the  SDB  Manager  and  the  APITESTER  applications.  The  SDB  Manager 
application  performed  all  of  the  data  base  management  functions  that  were  identified  for 
inclusion  into  the  GCCS  SDBM.  The  SDB  Manager  allowed  the  user  to  create  new  data  bases, 
add  products  to  new  and/or  existing  data  bases,  validated  products  before  importing  into 
existing  data  bases,  and  query  information  about  existing  data  bases.  The  APITESTER 
application  was  a  driver  used  to  test  the  data  access  functions  identified  for  the  GCCS  SDBM. 
Along  with  being  a  test  driver  it  also  proved  to  be  a  working  example  to  developers  and 
integrators  in  the  area  of  the  data  access  functions. 

The  third  phase  of  this  effort  was  the  final  briefing  and  demonstration  phase.  This  phase  of  the 
program  consisted  of  a  final  briefing  to  identify  and  conclude  the  activities  performed  under  the 
GCCS  SDBM  effort.  This  briefing  was  presented  to  DMA  and  other  GCCS  development  team 
members.  In  addition  to  the  final  briefing,  a  proof-of-concept  demonstration  was  assembled  to 
technically  support  the  activities  under  this  effort.  In  the  proof-of-concepts  demonstration,  the 
data  access  functions  exercised  and  tested  in  the  APITESTER  application  were  integrated  into 
an  existing  application  known  as  G-Odesy,  which  was  developed  under  an  earlier  U.S.  Air 
Force  contract  (Common  Mapping  Interface  Control  [CMIC]).  The  reasons  for  integrating  the 
API  functions  into  an  existing  CMTK  application  was  two  fold.  The  first  reason  for  the 
integration  was  to  demonstrate  that  the  API  function  could  be  called  from  an  application  to 
access  the  products  imported  into  the  SDBM  and  perform  queries  on  information  about  these 
products.  The  second  reason  for  the  integration  demonstration  was  to  re-enforce  the  migration 
concepts  set  forth  by  Sterling  Software,  for  transitioning  the  CMTK-to-JMTK. 

All  phases  were  successfully  completed,  demonstrated,  and  accepted  by  the  GCCS  JMTK 
Working  Group  for  inclusion  into  the  GCCS  COE  JMTK. 

5.2  Conclusions 

Several  conclusions  can  be  formulated  from  the  results  obtained  from  the  overall  GCCS  SDBM 
effort. 
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The  success  to  date  of  the  SDBM  can  be  attributed  to  several  factors.  The  first  and  most 
significant  factor  is  the  evolving  of  SDBM  using  a  modular  methodology.  The  benefits  can 
clearly  be  seen  for  the  importance  of  modularity  in  a  diverse  development  environment.  Under 
the  SDBM  effort,  the  development  team  consisted  of  three  contractors  that  conducted  their  own 
development  at  their  own  sites.  In  an  environment  such  as  this,  one  might  expect  many 
development  arid  integration  problems.  Well  defined,  modular  software  development  practices 
proved  to  be  one  of  the  major  success  factors  of  the  SDBM  effort.  Subsequent  integration  of 
Sterling  Software's  SDBM  API  functions  into  other  application  proved  to  be  insignificant  and 
not  time  consuming.  Secondly,  the  internet  connections  that  were  established  earlier  on  in  this 
contract  with  the  development  and  integration  sites  played  a  significant  rcie  in  the  overall 
software  development  on  this  effort.  Implementation,  integration,  testing,  and  trouble  shooting 
were  all  done  via  an  internet  connection  set  up  between  Sterling's  development  facilities  and  the 
GCCS  JMTK  integration  sites.  This  was  most  useful  in  the  areas  of  providing  updates  to  existing 
software  and  trouble  shooting  implementation  issues.  Updates  were  performed  instantaneously 
with  only  developers  interaction,  questions  concerning  delivered  software  were  tested  and 
addressed,  and  configuration  management  was  maintained.  By  utilizing  these  concepts  it 
provided  a  substantial  cost  savings  to  both  the  customer  and  Sterling  Software. 

Under  this  SDBM  effort,  the  prototype  implementation  of  SDBM  with  CMTK  proves  that  the 
migration  plan  is  a  feasible  approach.  The  benefits  that  could  be  achieved  under  this  approach 
are: 

An  interface  layer  between  the  CMTK  data  access  calls  and  SDBM,  when  implemented, 
would  allow  for  the  expansion  of  the  CMTK  data  sources. 

b.  Substitution  of  the  CMTK  preprocessor  with  the  SDB  Manager  import  application 
would  replaced  ~TOO,O0O  lines  of  code  with  —20,000  lines  of  GCCS  JMTK  code. 

c.  As  CMTK  functionality  migrates  closer  to  JMTK,  a  further  reduction  in  the  total  number 
of  maintainable  lines  of  code  would  exist. 

d.  The  migration  plan  would  allow  current  CMTK  applications  to  remain  identical  to  the 
end  user. 

5.3  Recommendations 

Enhancements  are  necessary  to  continue  to  evolve  any  system.  Several  recommendations  have 
been  made  for  enhancing  the  GCCS  SDBM  data  access  functionality  and  the  overall  design  and 
development  of  the  system.  The  six  following  specific  recommendations  have  been  noted: 

1.  The  implementation  of  public  API  functions  to  create,  manipulate,  and  delete  data  bases 
and  product  datasets. 

2.  Secondary  VPF  tables  for  processing  data  would  allow  for  quicker  access  times. 

3.  Automating  the  import  process  of  the  product  data  to  provide  a  more  user  friendly 
process. 

4.  Add  the  capability  to  track  the  import  process  as  it  completes  its  tasks.  A  "Gas  Gauge" 
could  potentially  be  added  to  the  SDBM  to  monitor  the  import  process  and  report  back  to 
the  user  with  "percentage  complete"  information. 

5.  Dissemination  of  design  and  development  information  via  the  use  of  collaborative 
engineering  tools. 

6.  A  firm  confirmation  to  adopt  the  CMTK-to-JMTK  migration  plan. 
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The  process  of  transitioning  a  system  to  a  working  environment  is  a  painstaking  undertaking. 
These  recommendations  surely  will  provide  for  a  easier  transition  from  the  laboratory  to  a  real- 
life  environment.  However,  this  does  not  provide  complete  closure  for  all  areas  that  might  need 
to  be  enhanced.  This  only  identifies  a  very  small  portion.  The  continued  success  of  the  GCCS 
SDBM  effort  is  the  recognition  of  potential  improvements  and  to  take  a  step  forward  to 
embrace  the  recommendations. 
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Appendix  A  SDBM  Test  Analysis 


A .  1  Identification 

This  appendix  summarizes  and  evaluates  the  results  of  testing  the  Spatial  Data  Base  Module 
(SDBM)  Computer  Software  Configuration  Item  (CSCI)  of  the  Joint  Mapping  Toolkit  (JMTK). 

A  .2  Test  Overview 

The  demonstration  of  the  functionality  of  the  Joint  Mapping  Toolkit  Spatial  Data  Base  Module 
CSCI  version  3.0  was  conducted  at  Sterling  Software/ITD,  Beeches  Technical  Campus,  Route 
26N,  Re- .':0,  i\Tew  Yoik.  The  execution  of  the  Formal  Qualification  Tests  (FQT)  was  held  on 
March  21-22,  1996,  witnessed  by  an  Air  Force  representative  of  Rome  Laboratory.  The 
hardware  and  software  configuration  used  during  the  FQT  is  detailed  below. 


The  Formal  Qualification  Tests  consist  of: 

1 .  Spatial  Data  Import 

Import  VPF  Product  from  CD-ROM 
Import  RPF  Product 
Import  Other  MC&G  Formats 
JMTK  Application  Data  Import 

2.  Spatial  Data  Management 

3.  Spatial  Data  Services 

Data  Base  Inventory  Retrieval 
Metadata  Retrieval 
Data  Retrieval 

Area-of-Interest  (AOI)  Creation 


Demonstration  Test  Record 


Hardware  Configuration:  Sun  SPARC  IPC 

Software  Configuration:  SunOS  version  5.4  (Solaris  2.4) 

TRITEAL  Corporation  Common  Desktop  Environment  (CDE) 

Motif  1.2.2 

X11R5 

SDBM  version  3.0 


Location: 


Testing  Dates: 
Attendees: 


Sterling  Software 
Information  Technology  Division 
Rome,  New  York 

March  21-22,  1996 

Major  Robert  Gibson,  USAF  Rome  Laboratory 
Mr.  Paul  Bell,  Sterling  Software/ITD 
Mr.  David  Kane,  Sterling  Software/ITD 
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Formal  Test  1,  Spatial  Data  Import: 

•  Import  VPF  Product  from  CD-ROM 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  1,  Import  VPF  Product  from  CD-ROM. 

•  Import  VPF-Product  from  CD-ROM  Summary 

The  Spatial  Data  Import  tests  were  designed  to  demonstrate  the  SDBM's  capability  to 
populate  an  existing  spatial  data  base.  The  Import  VPF  Product  from  CD-ROM  test 
demonstrated  the  capability  of  the  SDBM  to  import  Defense  Mapping  Agency  Vector 
Product  Format  data  from  a  CD-ROM  into  an  existing  SDBM  data  base.  The  table  depicted 
in  Figure  A-l  summarizes  the  results  of  this  test. 

•  Import  VPF  Product  from  CD-ROM  Record 

Tire  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  i  est  Record 
found  in  Section  A.2. 


Formal  Test  1,  Spatial  Data  Import 

Success 

Failure/Errors 

Remarks 

Import  VPF  Product  from  CD-ROM 

X 

None 

None 

Figure  A-1.  Spatial  Data  Import  -  Import  VPF  Product  from  CD-ROM 


Formal  Test  2,  Spatial  Data  Import: 

•  Import  RPF  Product 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  2,  Import  RPF  Product. 

•  Import  RPF  Product  Summary 

The  Spatial  Data  Import  tests  were  designed  to  demonstrate  the  SDBM's  capability  to 
populate  an  existing  spatial  data  base.  The  Import  RPF  Product  test  demonstrated  the 
capability  of  the  SDBM  to  import  Defense  Mapping  Agency  Raster  Product  Format  (RPF) 
data  into  an  existing  SDBM  data  base.  The  table  depicted  in  Figure  A-2  summarizes  the 
results  of  this  test. 

•  Import  RPF  Product  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A. 2. 


Formal  Test  2,  Spatial  Data  Import 

Success 

Failure/Errors 

Remarks 

Import  RPF  Product 

X 

None 

None 

Figure  A-2.  Spatial  Data  Import  -  Import  RPF  Product 
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Formal  Test  3,  Spatial  Data  Import 

•  Import  Other  MC&G  Formats 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  3,  Import  Other  MC&G  Formats. 

•  Import  Other  MC&G  Formats  Summary 

The  Spatial  Data  Import  tests  were  designed  to  demonstrate  the  SDBM's  capability  to 
populate  an  existing  spatial  data  base.  The  Import  Other  MC&G  Formats  test  demonstrated 
the  capability  of  the  SDBM  to  import  Mapping,  Cartography  &  Geodesy  data  from  a  source 
other  than  a  Vector  or  Raster  format  into  an  existing  SDBM  data  base.  This  test  involved 
importing  Digital  Terrain  Elevation  Data  into  a  previously  generated  Spatial  Data  Base.  The 
table  depicted  in  Figure  A-3  summarizes  the  results  of  this  test. 

•  Import  Oilier  MC&G  Formats  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 


Formal  Test  3,  Spatial  Data  Import 

Success 

Failure/Errors 

Remarks 

Import  Other  MC&G  Formats 

X 

None 

None 

Figure  A-3.  Spatial  Data  Import  -  Import  Other  MC&G  Formats 


Formal  Test  4,  Spatial  Data  Import 

•  JMTK  Application  Data  Import 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  4,  JMTK  Application  Data  Import. 

•  JMTK  Application  Data  Import  Summary 

The  Spatial  Data  Import  tests  were  designed  to  demonstrate  the  SDBM's  capability  to 
populate  an  existing  spatial  data  base.  The  JMTK  Application  Data  Import  test 
demonstrated  the  capability  of  the  SDBM  to  import  geospatial  and  graphic  data  generated 
by  a  JMTK  application  into  an  existing  SDBM  data  base.  The  table  depicted  in  Figure  A-4 
summarizes  the  results  of  this  test. 

•  JMTK  Application  Data  Import  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 


Formal  Test  4,  Spatial  Data  Import 

Success 

Failure/Errors 

Remarks 

JMTK  Application  Data  Import 

X 

None 

None 

Figure  A-4.  Spatial  Data  Import  -  JMTK  Application  Data  Import 
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Formal  Test  5,  Spatial  Data  Management 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  5,  Spatial  Data  Management. 

»  Spatial  Data  Management  Summary 

The  Spatial  Data  Management  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
manage  standard  DMA  product  formats  such  as  VPF,  RPF,  and  DTED  along  with  other 
MCG&I  data  that  may  not  be  in  a  recognizable  format.  The  Spatial  Data  Management  test 
demonstrated  the  capability  of  the  SDBM  to  create  and  maintain  data  bases,  create  and 
maintain  source  files  within  a  data  base,  and  report  the  data  base  contents.  The  test  also 
demonstrated  that  JMTK  users  have  the  ability  to  store  and  retrieve  data  base  contents,  as 
well  as  query  on  the  contents  of  a  SDBM  data  base  via  the  use  of  API-level  function  calls. 

The  table  depicted  in  Figure  A-5  summarizes  the  results  of  this  test. 

•  Spatial  Data  Management  Record 

The  testing  of  the  Spatial  Data  Management  functions  began  with  Formal  Test  5,  Spatial 
Data  Management  and  ended  with  Formal  Test  9,  Spatial  Data  Services  -  Area-of-Interest 
Creation,  which  encompassed  all  Formal  Tests.  The  date,  location,  test  personnel,  and 
witnesses  are  listed  in  the  Demonstration  Test  Record  found  in  Section  A.2. 


Formal  Test  5,  Spatial  Data  Mgmt 

Success 

Failure/Errors 

Remarks 

Spatial  Data  Management 

X 

None 

None 

Figure  A-5.  Spatial  Data  Management 


Formal  Test  6,  Spatial  Data  Services 

•  Data  Base  Inventory  Retrieval 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  6,  Spatial  Data  Services  -  Data  Base  Inventory 
Retrieval. 

•  Data  Base  Inventory  Retrieval  Summary 

The  Spatial  Data  Management  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
obtain  an  inventory  of  data  base  holdings.  The  Data  Base  Inventory  Retrieval  test 
demonstrated  the  capability  of  the  SDBM  to  retrieve  a  list  of  data  base  names,  geographic 
reference,  data  base  type,  scale  or  any  combination.  Also  verified  was  the  capability  of  the 
SDBM  to  retrieve  a  list  of  volumes  within  the  data  base  as  well  as  the  list  of  datasets  for 
each  volume.  The  table  depicted  in  Figure  A-6  summarizes  the  results  of  this  test. 

•  Data  Base  Inventory  Retrieval  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 


Formal  Test  6,  Spatial  Data  Services 

Success 

Failure/Errors 

Remarks 

Data  Base  Inventory  Retrieval 

X 

None 

None 

Figure  A-6.  Spatial  Data  Services  -  Data  Base  Inventory  Retrieval 
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Formal  Test  7,  Spatial  Data  Services 

•  Metadata  Retrieval 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  7,  Spatial  Data  Services  -  Metadata  Retrieval. 

•  Metadata  Retrieval  Summary 

The  Spatial  Data  Management  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
obtain  an  inventory  of  data  base  holdings.  The  Metadata  Retrieval  test  demonstrated  the 
capability  of  the  SDBM  to  provide  sufficient  metadata  for  each  dataset  and/or  format  as 
well  as  the  overall  dataset  so  as  to  properly  describe  the  data  base,  manage  its  holdings  and 
support  data  access.  The  Metadata  Retrieval  test  will  verify  that  the  SDBM  can  retrieve 
metadata  describing  an  individual  data  base  including  the  data  base  name,  geographic 
boimas,  total  rise  in  bytes,  number  of  volumes,  on  line  status  and  SDBM  version  identifier. 
Also  verified  was  the  ability  of  the  SDBM  to  retrieve  metadata  for  a  volume  within  the  data 
base.  The  table  depicted  in  Figure  A-7  summarizes  the  results  of  this  test. 

•  Metadata  Retrieval  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 
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Figure  A-7.  Spatial  Data  Services  -  Metadata  Retrieval 


Formal  Test  8,  Spatial  Data  Services 

•  Data  Retrieval 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  in  Formal  Test  8,  Spatial  Data  Services  -  Data  Retrieval. 

•  Data  Retrieval  Summary 

The  Spatial  Data  Management  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
obtain  an  inventory  of  data  base  holdings.  The  Data  Retrieval  test  demonstrated  the 
capability  of  the  SDBM  to  retrieve  any  data  product  that  is  stored  in  the  spatial  data  base. 
The  table  depicted  in  Figure  A-8  summarizes  the  results  of  this  test. 

•  Data  Retrieval  Record 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 
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Figure  A-8.  Spatial  Data  Services  -  Data  Retrieval 
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Formal  Test  9,  Spatial  Data  Services 

•  Area-of-Interest  (AOI)  Creation 

The  following  subparagraphs  provide  an  overview  of  the  test  results  obtained  from  exercising 
the  capabilities  defined  ir.  Formal  Test  9.  Spatial  Data  Services  -  Area-of-Interest  Creation. 

*  Ai'ea-of-Inierest  Creation 

The  Spatial  Data  Management  test  was  designed  to  demonstrate  the  SDBM's  capability  to 
support  AOI  creation  which  defines  a  geographic  region  that  an  application  intends  to 
interact  with.  The  Area-of-Interest  Creation  test  demonstrated  the  capability  of  the  SDBM  to 
support  the  definition  of  an  area-of-interest  which  defines  a  geographic  region  that  an 
application  intends  to  interact  with.  The  table  depicted  in  Figure  A-9  summarizes  the  results 
of  this  test. 

f  Area-of  Interest  Creation  Record. 

The  date,  location,  test  personnel,  and  witnesses  are  listed  in  the  Demonstration  Test  Record 
found  in  Section  A.2. 
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Figure  A-9.  Spatial  Data  Services  —  Area-of-interest  (AOI)  Creation 


A. 3  Joint  Mapping  Toolkit/Spatial  Data  Base  Module  Test  Results 

For  each  of  the  nine  tests  performed,  the  expected  results  identified  in  the  Software  Test 
Description  for  the  Joint  Mapping  Toolkit /Spatial  Data  Base  Module  matched  the  events/ 
outcome  displayed  on  the  screen  during  testing.  As  a  result  the  outcome  of  the  tests  performed 
to  verify  the  compliance  of  the  Joint  Mapping  Toolkit/Spatial  Data  Base  Module  to  the 
requirements  identified  in  the  Software  Test  Plan  for  the  Joint  Mapping  Toolkit/Spatial  Data 
Base  Module  should  be  considered  successful. 
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Appendix  B  Acronyms 


ADRG 

ARC  Digitized  Raster  Graphics 

ADRI 

ARC  Digitized  Raster  Imagery 

AFMSS 

Air  Force  Mission  Support  System 

AOI 

Area-of-Interest 

API 

Application  Progiammer  Interface 

C3I 

Command,  Control,  Communications,  and  Intelligence 

C4I 

Command,  Control,  Communications,  Computers,  and 
Intelligence 

CADRG 

Compressed  ARC  Digital  Raster  Graphics 

CD 

Compact  Disk 

CD-ROM 

Compact  Disk-Read  Only  Memory 

CDE 

Common  Desktop  Environment 

CIB 

Controlled  Image  Base 

CM 

Configuration  Management 

CMIC 

Common  Mapping  Interface  Control 

CMS 

Common  Mapping  Standard 

CMTK 

Common  Mapping  Toolkit 

COE 

Common  Operating  Environment 

COTS 

Commercial-Off-The-Shelf 

CSCI 

Computer  Software  Configuration  Item 

DCW 

Digital  Chart  of  the  World 

DFAD 

Digital  Feature  Analysis  Data 

DIS 

Data  Interchange  Services 

DISA 

Defense  Information  Systems  Agency 

DMA 

Defense  Mapping  Agency 

DoD 

Department  of  Defense 

DTED 

Digital  Terrain  Elevation  Data 

EA 

Evolutionary  Acquisition 

ED 

Evolutionary  Development 

ELV 

Elevation 

FGDC 

Federal  Geographic  Data  Committee 

FQT 

Formal  Qualification  Test 

GCCS 

Global  Command  and  Control  System 

GIS 

Geographical  Information  System 

B-l 


GOTS 

IRRP 

ITD 

JMTK 

JSWG 

MACS 

MC&G 

MCG&J 

NDC 

N1TF 


PDC 

R&D 

RL 

RPF 

SDB 

SDBM 

SDT 

SOW 

SRS 

TBMCS 

TEM 

U.S. 

USAF 

VMAP 

VPF 

VSC 

WWMCCS 


Govemment-Off-The-Shelf 

Rome  Laboratory's  Image  Products  Branch 
Information  Technology  Division 

Joint  Mapping  Toolkit 
Joint  Services  Working  Group 

Mapping  Application  Client  Server 
Mopping,  Charting  and  Geodesy 
Mapping,  Charting,  Geodesy,  and  Imagery 

Normalized  Device  Coordinates 
National  Imagery  Transmission  Format 

Physical  Device  Coordinates 

Research  and  Development 
Rome  Laboratory 
Raster  Product  Format 

Spatial  Data  Base 

Spatial  Data  Base  Module 

Spatial  Display  Tool 

Statement  of  Work 

Software  Requirements  Specification 

Theater  Battle  Management  Core  System 
Topographic  Evaluation  Module 

United  States 
United  States  Air  Force 

Vector  Smart  Map 
Vector  Product  Format 
View  Surface  Coordinates 

World-Wide  Military  Command  and  Control  System 
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Appendix  C  Glossary 


Application  Programmer's  Interface  (API):  A  paradigm  used  to  provide  the  interfaces  between  an 
application  and  a  software  library  of  functions,  a  toolkit  of  functions,- or  another  application. 
The  API  can  also  refer  to  a  collection  of  functions  providing  the  interface  capability  to  a 
software  library,  a  toolkit  of  functions,  or  another  application. 

Cartographic  Display  Process:  The  method  used  to  draw  a  cartographic  map  feature  (e.g.,  VPF 
data  features)  in  the  CMTK  cartographic  window. 

Common  Mapping  Toolkit  (CMTK):  A  software  library  of  functions  which  provide  the  capability 
to  display,  manipulate,  perform  geospatial  analysis,  and  otherwise  exploit  Common  Mapping 
Standard  (CMS)  data  (preprocessed  from  DMA  standard  data)  as  well  as  other  data  sources 
for  the  United  States  Air  Force. 

Common  Mapping  Standard  (CMS):  A  standardized.  Government-owned  and  DMA-validated 
cartographic  data  base  structure  used  as  the  CMTK  data  base.  The  data  it  incorporates  is 
imported  from  existing  DMA  data  products  such  as  ADRG,  ADRI,  DCW,  DFAD,  DTED,  etc.  It 
provides  a  common  format  for  the  use  of  these  varying  DMA  data  products. 

Compressed  ARC  Digitized  Raster  Graphic  (CADRG):  A  general  purpose  product,  comprising 
computer-readable  digital  map  and  chart  images.  It  supports  various  weapons:  Command, 
Control,  Communications,  and  Intelligence  (C3I)  theater  battle  management;  mission  planning; 
and  digital  moving  map  systems.  CADRG  data  is  derived  directly  from  ADRG  and  other  digital 
sources  through  down  sampling,  filtering,  compression,  and  reformatting  to  the  RPF  Standard. 
CADRG  files  may  be  physically  formatted  within  a  NTTF  message. 

Controlled  Image  Base  (CIB):  A  dataset  of  orthonormalized  and  rectified  grayscale  images.  A 
CIB  supports  various  weapons,  C3I  theater  battle  management,  mission  planning,  and  digital 
moving  map  systems.  CIB  data  are  derived  and  produced  directly  from  digital  images,  and  are 
compressed  and  reformatted  to  conform  to  the  RPF  Standard. 

Dataset  Metadata:  A  Level  3  metadata  file  within  an  SDBM  Spatial  Data  Base.  It  describes  a 
particular  dataset  found  within  a  data  base. 

Data  Base  Metadata:  The  top  level  (Level  1)  of  metadata  within  an  SDBM  Spatial  Data  Base.  It 
describes  the  contents  of  a  particular  data  base. 

Digital  Chart  of  the  World  (DCW):  A  DMA  product  providing  1:1,000,000  scale  vector 
geographic  data.  DCW  was  developed  as  the  initial  product  implementation  of  a  multinational 
R&D  project  designed  to  develop  a  set  of  vector  product  standards  oriented  toward  the 
Geographical  Information  System  (GIS)  environment.  DCW  data  was  derived  from  Operational 
Navigational  Charts  over  most  of  the  globe  and  Jet  Navigational  Charts  over  Antarctica.  The 
DCW  product  is  the  original  name  for  the  current  VPF  standard  product,  VMAP  Level  0. 

Digital  Terrain  Elevation  Data  (DTED):  A  DMA  product  providing  a  uniform  matrix  of  terrain 
elevation  values  for  the  earth's  surface  at  100  meter  resolution.  The  information  content  is 
approximately  equivalent  to  a  1:250,000  scale  resolution. 

GCCS  Common  Operating  Environment  (COE):  Defines  a  distributed  application  infrastructure 
that  promotes  interoperability  in  a  reliable  and  scalable  environment.  Specifically,  a  set  of 
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integrated  services  that  support  mission  software  application  requirements,  and  a 
corresponding  software  development  methodology  and  environment. 

Geographic  Reference  System  (GEOREF):  A  system  used  for  position  reporting.  It  is  an  area- 
designation  method  used  for  interservice  and  interallied  position  reporting  for  air  defense  and 
strategic  operations.  Positions  are  expressed  in  a  form  suitable  for  reporting  and  plotting  on  any 
map  or  chart  graduated  in  latitude  and  longitude  (with  Greenwich  as  prime  meridian) 
regardless  of  map  projection.  Referred  to  as  GEOREF. 

G-Odesy:  An  application  which  exercises  ?.  major  portion  of  the  CMTK  API-level  functions.  It 
was  developed  during  the  CMC  effort  and  is  used  to  provide  developers  with  an  environment 
conducive  to  modifying,  testing,  and  exercising  any  portion  of  the  CMTK  source  code  quickly 
and  easily. 

Global  Command  and  Control  System  (GCCS):  Will  become  the  single  Command,  Control, 
Communications,  Computers,  and  Intelligence  (C4I)  system  to  support  Joint  warfighter.  The 
system  objectives  are  to  replace  the  World-Wide  Military  Command  and  Control  System 
(WWMCCS),  and  to  implement  the  C4I  for  the  Warrior  concept.  The  result  will  be  a  single  view 
of  the  military  C4I  that  improves  the  Joint  warfighter's  ability  to  manage  and  execute 
operations. 

Graphics  Transformation:  The  conversion  of  points  from  one  coordinate  system  to  another  using 
a  transformation  matrix.  Graphics  transformations  include  translation,  scaling,  and  rotation. 

Joint  Mapping  Toolkit  (JMTK):  A  collection  of  application  programmer  interfaces  (APIs)  that 
enable  support  applications  to  interface  with  Mapping,  Charting,  Geopositioning,  and  Imagery 
(MCG&I)  functionality.  This  release  of  JMTK  (version  3.0)  is  comprised  of  three  distinct 
modules  that  interact  with  each  other  through  the  defined  APIs.  The  Visual  Module  provides 
map  presentation  functionality.  The  Analysis  Module  performs  geospatial  computations.  The 
Spatial  Data  Base  Module  provides  the  geospatial  data  management  services. 

National  Imagery  Transmission  Format  (NITF):  A  collection  of  related  standards  and 
specifications  developed  to  provide  a  foundation  for  interoperability  in  the  dissemination  of 
imagery  and  imagery-related  products  among  different  computer  systems,  as  defined  in  MIL- 
STD-2500. 

Normalized  Device  Coordinates  (NDC):  A  coordinate  system  used  to  address  pixels  on  a 
computer  graphics  screen.  The  range  of  this  coordinate  system  is  similar  to  physical  device 
coordinates,  except  that  the  largest  dimension  (width  or  height)  is  set  to  1.0.  The  NDC  position 
(0.0,  0.0)  is  in  the  lower  left  comer  of  the  screen.  If  the  width  and  height  are  equal,  then  the 
upper  right  corner  of  the  screen  is  NDC  position  (1.0, 1.0).  If  NDC  coordinates  are  used,  then 
graphics  objects  will  take  up  the  same  proportion  of  all  computer  screens,  regardless  of  the 
actual  PDC  dimensions  of  the  screen. 

Physical  Device  Coordinates  (PDC):  A  standard  coordinate  system  used  to  address  pixels  on  a 
computer  graphics  screen.  The  range  of  this  coordinate  system  is  dependent,  but  in  a  typical 
system  the  PDC  of  the  upper  left  pixel  will  be  (0,  0)  and  the  PDC  of  the  lower  left  pixel  will  be 
(width-1,  height-1),  where  width  is  the  number  of  pixels  across  the  screen  in  the  horizontal 
direction,  and  height  is  the  number  of  pixels  across  the  screen  in  the  vertical  direction.  Some 
systems  may  have  PDC  (0,  0)  in  a  different  corner  and  PDC  (width-1,  height-1)  in  the 
diagonally  opposite  comer. 

Pixel:  A  picture  element.  The  smallest  addressable  area  of  a  computer  screen  or  image  file. 
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Raster  Product  Format  (RPF):  A  standard  data  structure  for  geospatial  data  bases  composed  of 
rectangular  arrays  of  pixel  values  (e.g.,  digitized  maps  or  images)  in  compressed  or 
uncompressed  form.  RPF  is  intended  to  enable  application  software  to  use  the  data  in  the 
original  format  on  computer-readable  interchange  media  directly  without  further  manipulations 
or  transformations. 

Rotation:  A  graphics  transformation  in  which  a  coordinate  system  is  rotated  about  its  origin  by 
a  fixed  angular  value. 

Scaling:  A  graphics  transformation  in  which  a  coordinate  system  is  resized  into  a  larger  or 
smaller  coordinate  system  with  possibly  a  different  aspect  ratio. 

Spatial  Data  Base  Module  (SDBM):  The  module  within  the  Joint  Mapping  Toolkit  representing  all 
activities  dealing  with  data  handling.  Those  areas  include  spatial  data  import,  spatial  data 
management,  spatial  data  manipulation,  spatial  data  base  services,  and  spatial  data  export. 

Spatial  Display  Tool  (Sdt):  An  application  developed  to  provide  a  single  comprehensive,  digital 
multisource  MCG&I  information  handling  capability. 

Thread  Tracker:  A  utility  developed  during  the  development  of  JMTK  3.0.  It  provides  the 
capability  to  track  the  functional  hierarchy,  or  functional  threads,  within  a  toolkit  of  functions 
during  execution  time.  It  can  be  turned  off  and  on  as  needed. 

Transformation  Matrix:  A  3x3  matrix  to  be  multiplied  by  a  point  (stored  as  a  vector)  to  produce 
a  corresponding  point  (vector)  in  a  different  coordinate  system.  A  3x3  matrix  will  transform  a 
two  dimensional  point.  A  transformation  matrix  can  be  as  simple  as  an  identity  matrix,  in 
which  case  the  output  is  identical  to  the  input,  or  any  combination  of  translation,  scaling,  and 
rotation  matrices. 

Translation:  A  graphics  transformation  in  which  a  coordinate  system  is  moved  vertically  and/or 
horizontally. 

Vector  Product  Format  (VPF):  The  DMA's  standard  format  for  vector  data.  A  general  user- 
oriented  data  format  for  representing  large  spatially  referenced  data  bases.  VPF  is  designed  to 
be  used  directly  where  software  can  access  the  data  without  time  consuming  conversion 
processing.  VPF  is  also  designed  to  be  compatible  with  a  wide  variety  of  users,  applications, 
and  products. 

Vector  Smart  Map  (VMAP)  Level  0:  The  low  resolution  component  of  DMA's  VMAP  family  of 
products.  Known  as  VMAP  Level  0,  it  is  a  comprehensive  1: 1,000,000-scale  vector  basemap  of 
the  world.  It  consists  of  geographic,  attribute,  and  textual  data  stored  on  CD-ROMs.  To  show 
product  lineage,  it  is  dual  named  VMAP  Level  0  as  well  as  Digital  Chart  of  the  World  (DCW). 
The  name  VMAP  Level  0  will  be  the  only  name  to  continue  beyond  the  initial  release  of  the 
Vector  Smart  Map  Level  0  data. 

View  Surface  Coordinates  (VSC):  A  coordinate  system  used  to  address  pixels  on  a  computer 
screen.  The  range  of  this  coordinate  system  is  the  same  as  that  of  PDC,  but  on  all  systems  the 
VSC  of  the  lower  left  pixel  will  be  (0,  0),  and  the  VSC  of  the  upper  right  pixel  will  be  (width-1, 
height-1).  VSC  should  be  used  in  place  of  PDC  wherever  possible  to  allow  for  system 
portability. 

Volume  Metadata:  A  Level  2  metadata  file  within  an  SDBM  Spatial  Data  Base.  It  describes  the 
data  types  (i.e.,  DCW,  CADRG,  DTED)  found  within  a  data  base  and  the  datasets  present  for 
a  data  type. 
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MISSION 

OF 

AFRL/INFORMATION  DIRECTORATE  (IF) 


The  advancement  and  application  of  information  systems  science  and 
technology  for  aerospace  command  and  control  and  its  transition  to  air, 
space,  and  ground  systems  to  meet  customer  needs  in  the  areas  of  Global 
Awareness,  Dynamic  Planning  and  Execution,  and  Global  Information 
Exchange  is  the  focus  of  this  AFRL  organization.  The  directorate’s  areas 
of  investigation  include  a  broad  spectrum  of  information  and  fusion, 
communication,  collaborative  environment  and  modeling  and  simulation, 
defensive  information  warfare,  and  intelligent  information  systems 
technologies. 


